Conversation
a930739 to
f6981c9
Compare
Doc/Makefile
Outdated
| .PHONY: venv-pdf | ||
| venv-pdf: | ||
| @if [ -d $(VENVDIR_PDF) ] ; then \ | ||
| echo "venv-pdf already exists."; \ | ||
| echo "To recreate it, remove it first with \`make clean-venv'."; \ | ||
| else \ | ||
| set -e; \ | ||
| echo "Creating venv in $(VENVDIR_PDF)"; \ | ||
| if $(UV) --version >/dev/null 2>&1; then \ | ||
| $(UV) venv --python=$(PYTHON) $(VENVDIR_PDF); \ | ||
| VIRTUAL_ENV=$(VENVDIR_PDF) $(UV) pip install -r requirements-pdf.txt; \ | ||
| else \ | ||
| $(PYTHON) -m venv $(VENVDIR_PDF); \ | ||
| $(VENVDIR_PDF)/bin/python3 -m pip install --upgrade pip; \ | ||
| $(VENVDIR_PDF)/bin/python3 -m pip install -r requirements-pdf.txt; \ | ||
| fi; \ | ||
| echo "The venv has been created in the $(VENVDIR_PDF) directory"; \ | ||
| fi | ||
|
|
There was a problem hiding this comment.
This is essentially identical to venv, except instead of the REQUIREMENTS variable it hardcodes requirements-pdf.txt.
Can dist-pdf instead invoke venv and set REQUIREMENTS to requirements-pdf.txt?
There was a problem hiding this comment.
Hm, it would be a nice simplification, though after the change two different virtualenvs would share the same location, incorrectly recognising existence of each other.
e.g.
(1) make html -> creates new venv (regular), builds html
(2) then make pdf -> it says venv already exists, therefore we don't rebuild the venv and try to build pdf without extra depenendency
There was a problem hiding this comment.
Oh, sorry, actually I can also set VENVDIR, I will try it tomorrow.
There was a problem hiding this comment.
Implemented in 9cb3ba4. I kept the venv-pdf target and reverted adding the dependency from dist-pdf to venv-pdf, for consequence with other dist- targets. Though I made venv-pdf reuse existing venv target definition.
There was a problem hiding this comment.
(test run after changes: https://github.com/m-aciek/python-docs-offline/actions/runs/22770351164)
There was a problem hiding this comment.
Thanks, looks much better!
I'm wondering if we even need two named venvs.
Right now you can do:
(1) make html -> usual html build
(2) then make htmllive -> will also install the extra sphinx-autobuild dependency
Similarly for (3) make check -> installs pre-commit
Can we follow the same pattern?
There was a problem hiding this comment.
Thank you for catching that! Suggested approach is even more minimal. Implemented in 4b90701. I don't think we need to pin the package version as long as PDF build is not included in CPython's CI (otherwise I'd do it, for reproducible builds).
…svg2pdfconverter Makefile target
Fix PDF build of documentation.
sphinxcontrib.rsvgconverterfrom the package for converting of SVG graphics to PDF format.Refs. python/docs-community#182.
Test build is available here: https://github.com/m-aciek/python-docs-offline/actions/runs/22771888107. Artifacts include ZIP to download.
For the reference, problematic docs lines:
cpython/Doc/library/heapq.rst
Line 348 in 852ec18
cpython/Doc/library/datetime.rst
Line 157 in d3b6faf
cpython/Doc/library/profiling.sampling.rst
Line 1197 in 37430ca
cpython/Doc/library/profiling.sampling.rst
Line 1220 in 37430ca
📚 Documentation preview 📚: https://cpython-previews--145480.org.readthedocs.build/